Handle fallible per commitment point in channel establishment #3109
Conversation
alecchendev
force-pushed
the
2024-06-async-commit-point-funding
branch
from
3fbf2e6
to
1e5b210
Compare
|
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #3109 +/- ##
==========================================
- Coverage 89.81% 89.78% -0.03%
==========================================
Files 121 119 -2
Lines 99314 97966 -1348
Branches 99314 97966 -1348
==========================================
- Hits 89195 87955 -1240
+ Misses 7514 7435 -79
+ Partials 2605 2576 -29 ☔ View full report in Codecov by Sentry. |
alecchendev
force-pushed
the
2024-06-async-commit-point-funding
branch
from
1e5b210
to
07991fa
Compare
|
the commits from #3115 are second from the end, will rebase on top later this week, but generally most of the stuff here is in place |
alecchendev
force-pushed
the
2024-06-async-commit-point-funding
branch
from
07991fa
to
744f2ca
Compare
alecchendev
force-pushed
the
2024-06-async-commit-point-funding
branch
3 times, most recently
from
73583e7
to
b798ffa
Compare
| // TODO: add a variant for before our first commitment point is retrieved | ||
| /// We have just created or accepted a channel and are pending our very | ||
| /// first commitment point. | ||
| Uninitialized { transaction_number: u64 }, |
There was a problem hiding this comment.
I thought we were going to first handle all the async cases post-funding and then add support for handling the async case during initial channel bring up in a separate PR?
There was a problem hiding this comment.
sorry for the delay, yea you're right, i just forgot! will be back to prioritizing this next week
There was a problem hiding this comment.
just put up #3150 - will rebase this PR on top of that when i get time
This attempts to refine the signer pending flag mutations + move some signer flag logic into the `signer_unblocked` method instead of our other lightning logic. Before flow: - Call function that asks for signature - if absent, sets signer pending flag - if present, clear signer pending flag - Call `signer_unblocked` -> call the function again, and it'll set the flags again depending on the result After flow: - Call function that asks for signature - if absent, sets signer pending flag - Call `signer_unblocked` -> clear the signer pending flag -> call the function again, and it only resets the flag if unsuccessful This moves the logic for all async commitment signatures, i.e. funding_created, funding_signed, and commitment_signed.
Includes simple changes to test util signers and tests, as well as handling the error case for get_per_commitment_point in HolderCommitmentPoint. This leaves a couple `.expect`s in places that will be addressed in a separate PR for handling funding.
Note: this does not test the CS -> RAA resend ordering, because this requires handling async get_per_commitment_point for channel reestablishment, which will be addressed in a follow up PR.
alecchendev
force-pushed
the
2024-06-async-commit-point-funding
branch
from
b798ffa
to
0bdd4cc
Compare
Builds on
#3086,#3096,#3115, #3149, #3150. First PR to handle fallibleget_per_commitment_pointsigner method.We make
get_per_commitment_pointreturn a result type so that in theErrcase, we (LDK) can resume operation while an async signer fetches the commitment point. This will typically block sending out a message, but otherwise most state updates will occur. When the signature arrives, the user is expected to callChannelManager::signer_unblockedand we will retryget_per_commitment_pointhowever this time the signer will return the commitment point withOk, and we'll send out our message.This PR implements this flow for channel establishment, i.e.
open_channel,accept_channel, andchannel_ready.Rough outline of how our
HolderCommitmentPointadvances and gets new signatures:open_channel- creates new outbound channel, immediately requests the first commit point, waits to have the first 2 commit points to be unblocked to send the messageaccept_channel- same ^funding_created- no op regarding commit pointsfunding_created- uses point to verify first commitment, then advances commitment, requesting next pointfunding_signed- no opfunding_signed- same as above, verifies, advances, requests next pointchannel_ready- waits to have the next commit point ready, then once unblocked sends the current point in thechannel_readymessageTo do
channel_readyupon the signer being unblockedchannel_readyHolderCommitmentPointstruct to track commitment points #3086